對供應鏈管理的看法 （三）

對於APS因為有太多的教訓，或許會是最多想法的吧。

第四，APS其實是透過好幾個模組來cover不同的業務模組。主要可以分成：需求管理(demand management)、供給規劃 (supply planning)、訂單回覆(demand fulfillment)三大塊，而這三大塊裡面又有不同模組來提供不同的功能。

例如，需求管理是只將與客戶、銷售管道(channel)...等等不同來源的需求資訊透過資訊分享的方式收集到一個地方，讓需求的資訊可以讓所有相關人員看得到。這裡面談到與客戶、銷售管道的協同作業與資訊收集，這部份可以透過簡單的excel、文字檔傳遞一直到複雜的協作資訊系統整合來達到。然後再透過某個平台將需求資訊整合、顯示出來；這部份大都是將需求資訊以不同角度、不同維度呈現給相關人員。

而供給規劃就是透過一些演算法，考慮供給的限制計算出供給計畫來滿足需求。因為規劃區間的不同，供給規劃又有分成主生產排程(master production schedule, MPS)、細部的工單、採購單的計畫以及生產排程等等，這部份就請參照一些講MRP II的資料。

可以看到整個規劃的流程被切分成很多的步驟，而在這些步驟中進行資訊(資料)的傳遞，一棒接一棒完成一次次的循環。

首先，當一個公司發現它有供應鏈規劃的問題時，使用者知道該拿哪個模組來解決？對於需求管理與訂單回覆或許比較直觀，但是對於供給規劃上卻因為規劃區間不同，這些模組的功能、設計是有所區分的，並不是能夠一體適用的。

有些客戶他們的想法是「買一個系統，解決所有的事情」，所以買了主生產排程的工具，期望它能進行生產排程；或是買了物料需求規劃的模組，又希望它能夠協助進行各廠之間的產能分配合理化。而導入的團隊如果對於系統定位、客戶需求沒有辦法完全了解、清楚，就會造成雙方的痛苦。導入的一方會因為滿足客戶需求而整天與系統的gap奮鬥；客戶覺得為什麼簡單的業務需求沒有辦法做到。

其次，規劃是個動態系統 (dynamic system)，當需求資訊傳遞到供給規劃模組時，需求可能又已經變動了。這就是彼得聖吉在「第五項修煉」裡面所說的，一般的人缺乏「系統思考」(system thinking)。因為我們所受的教育訓練，一個大問題是可以被拆成數個可以處理、解決的小問題，然後一個一個解決這些小問題後大問題也就跟著被解決了。但是在一個動態系統裡，問題是有交互作用的，當採取一個行動時，會有回饋(feedback)，所以問題不是可拆解的。

有點離題，拉回來一下。例如：當我們進行供給規劃時，通常會看需求的時間、數量、客戶等等來決定優先等級，所以當有供應限制時，就可以將供給分配給優先級較高的需求。當銷售人員知道這樣的行為後，如果要「搶量」的時候，他們就會把需求預測放大、時間放早一些...等等來搶供給。

另外在供應「鏈」上的成員也會根據自己的判斷來決定相對的行動，而這些決定可能造成整體供應鏈上的波動，進而影響整體供應鏈的運作效率。有一個有名的實驗，叫做「啤酒遊戲」就可以演示這樣的行為。

所以這些APS將問題拆解後，系統之間需要更多的整合、資料傳遞，將規劃的時間拉長，進而就會遇到更大「動態系統」的問題。除非有一天系統能夠快到很快的完成end-to-end的規劃循環，使用者可以更快的進行整體規劃，用很短的時間由需求預測變動進行供給規劃，而透過規劃出來的供給計畫來答覆訂單。簡言之，以極短的時間減少系統變動造成的影響。

第五，系統只是輔助。(老梗是：左手只是輔助，出處詳見灌籃高手)

APS導入的成功，80%以上是靠使用者的流程、作業方式來決定。例如前面講到需求規劃，它是一個平台協助收集需求資訊，將需求的資訊在不同面向的不同維度中顯示出來，讓使用者方便檢視、管理。它收集來自銷售通路、客戶、銷售人員判斷...等不同來源的資訊，而呈現在一個平台上。講起來非常簡單，事實上很多人也都認為需求管理是最簡單的模組；但是魔鬼就在細節裡。

請問，銷售通路上有大盤、中盤、零售...等，誰要給你資訊？大盤的資訊怎麼來？中盤怎麼來？為什麼通路要給你資訊？對客戶而言，提供預測有什麼好處？即時供貨？如果是大咖的客戶，它不給你預測，單下來了，你接不接？小咖的乖乖的給預測，但是供給不足的時候，它都是第一個被犧牲的。(需求優先級，還記得嗎？) 公司內部的銷售人員呢？他給你預測，那是代表他的quota？光光這些問題就是作業上先要釐清處的，而這些問題釐清後，才能來談怎麼將資料呈現在平台上。

如果看訂單答覆，那更是複雜。誰說訂單一定根據ATP來達交？尤其在台灣以ODM/OEM為主的公司型態，訂單都是先接了再說。只怕沒單，不怕沒辦法交，不是嗎？

所以在導入APS時，有太多的業務流程、行為要先釐清，規則要講清楚(但是規則是講不清楚的)，才能將這些東西設計在系統裡面。所以系統的工，真的只有不到20%的effort。

但是這些賣軟體license的人，他一定跟你說：我內建best practice，你只要一樣畫葫蘆就好。因為他要你趕快買license，至於怎麼用、怎麼上線，那還有很多時間可以來好好討論，或是交給資訊服務商來處理。 (開始變成自白書了....XD)

有時候則是這些vendor對於系統也不是很清楚或是也不了解業務流程的重要性，所以他在賣的時候也不知道改變客戶現況讓系統有機會來支持客戶作業的effort是很大的，甚至是成功建置決定性的因素。這樣的錯誤認知下，APS的成功建置就不太可能了。

第六，使用者錯誤的期望

Steve Jobs說，”you can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new.”使用者剛開始接觸APS時，一定對它有個美麗而錯誤的期待：「一鍵到底、快樂無比」。他們會提出很多想像的需求，然後把建置系統的人搞到快瘋掉；但是開始驗證的時候，你卻發現他們其實不要用那些功能或者沒辦法用那些功能。

APS就是拿資料進去，根據你給的規則進行計算、呈現。所以你要給它 1.資料 2.規則。但是使用者有時候就是沒辦法「維護資料」，然後他就跟你說系統出來的結果「不對」、「不好」、「不正確」。然後使用者就會開始要你放「default」值或是給你另外的一套規則來產生一些必要的資料，然後又是一個輪迴。

另外使用者也可能會將一些很天馬行空的想法，希望作在系統裡。有時候，我甚至懷疑那是現在電腦科技可以實現的嗎？如果有個原子小金剛來訓練一陣子，那可能性還高些。

其實我也看到很多使用者有個很奇怪的心態：希望系統全自動，但是又怕自己的價值不見了。簡單講，有了原子小金剛，那還要你幹嘛？

講了這麼多，那該怎麼做呢？下次在繼續來聊這段。

(待續)